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A Mobile Computer System with A Robust 
Expansion Capability 

FFFT T) OF THE INVENTION 

5 

The present invention relates to the field of mobile computer 
systems. In particular the present invention discloses a computer system 
having an external physical interface and robust computer software that 
allows peripherals to be coupled to and decoupled from the physical interface 
1 0 while the computer system is operating. 

BACKGROUND OF THE INVENTION 

Mobile computer systems have become a very popular form of 
1 5 computing device. Mobile computer systems allow users to access large 
amounts of personal information such as an address book, a personal 
calendar, and a list of to-dos. In particular, the Palm® series of palm-sized 
computer systems from Palm Computing, Inc of Santa Clara, California have 
become the de facto standard of handheld computer systems. 



20 



To provide additional functionality, it is desirable to include an 
external hardware interface on the mobile computer system. The Palm® 
series of palm-sized computer systems includes an external serial interface for 
communicating with external peripherals. However, an external serial 
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interface is limited due to the limited communication bandwidth and limited 
interface features. 



It would therefore be desirable to provide a higher bandwidth 
and more feature laden external interface. Ideally, the external interface 
should be very simple to use such that the user does not need any training. 
Furthermore, the external Interface should be robust enough to handle any 
type of user behavior whether appropriate or not. 
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The present invention introduces a robust external interface for 
a computer system. The external interface allows a user to insert or remove 
external peripherals to the external interface at any time such that the user 
does not need to carefully follow any scripted procedures. The external 
interface software detects insertions or removals and acts in an appropriate 



manner. 



Other objects, features, and advantages of present invention will 
be apparent from the company drawings and from the following detailed 
description. 
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The objects, features, and advantages of the present invention 
will be apparent to one skilled in the art in view of the following detailed 
5 description in which: 



Figures 1 A and IB illustrate a mobile computer system with an 
external peripheral interface. 

1 o Figure 1C illustrates a block diagram of one possible software 

architecture for a mobile computer system. 

Figure 2 illustrates a flow diagram of the operations performed 
when a peripheral device is inserted into an expansion interface. 

15 

Figure 3 illustrates a flow diagram of the operations performed 
when a peripheral device is removed from an expansion interface. 

Figure 4 illustrates a state diagram of one possible peripheral 
20 insertion/removal interrupt generator. 

Figure 5 illustrates a flow diagram describing an interrupt 
routine for handling peripheral device insertions. 



25 Figure 6 illustrates a flow diagram describing an event handler 

for handling peripheral insertion events. 
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Figure 7 illustrates a flow diagram describing an installation 
routine for a set-up utility that accompanies a peripheral device and is 
executed upon peripheral insertion events. 

Figure 8 illustrates a flow diagram describing an interrupt 
routine for handling peripheral device removals. 

Figure 9 illustrates a flow diagram describing an event handler 
for handling peripheral removal events. 

Figure 10 illustrates a flow diagram describing a removal 
routine for a set-up utility that undoes changes made to the computer system 
by the installation routine of the set-up utility when the peripheral device was 
inserted. 

Figure 11 illustrates a flow diagram describing a bus error 
exception routine that handles bus errors caused by removing a peripheral 
device from a computer system. 

Figure 12 illustrates a flow diagram describing how the input 
alert pin can be used to identify and support external input devices. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

A method and apparatus for implementing a robust external 
interface for a computer system is disclosed. In the following description, for 
purposes of explanation, specific nomenclature is set forth to provide a 
thorough understanding of the present invention. However, it will be 
apparent to one skilled in the art that these specific details are not required in 
order to practice the present invention. For example, the present invention 
has been described with reference to handheld computer system. However, 
the same techniques can easily be applied to any other type of computer 
system. 

Extensible Mobile Computer System 

Figures 1 A and IB illustrate a mobile computer system 100 that 
includes an expansion interface 110. The expansion interface allows 
peripheral devices to be inserted and coupled directly to a bus of the mobile 
computer system 100. In one embodiment, an interrupt line from the 
processor in the mobile computer system 100 is coupled to the expansion 
interface 110 such that the processor can detect when a peripheral device is 
inserted or removed. A second interrupt line is provided as a signal on the 
expansion interface 110 such that a peripheral inserted into the expansion 
interface may obtain the attention of the processor. 

Figure lc illustrates one possible embodiment for a software 
architecture of the mobile computer system 100. As illustrated in Figure 1C, 
several device drivers 121, 123, and 125 are used to control the hardware 115 
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of the mobile computer system 100. The device drivers are accessed by an 
operating system 150. The operating system includes an event handler 160 
that processes a series of events placed in an event queue 161. The events 
may comprise interface events such as stylus strokes on a digitizer pad, 
button presses, menu selections, etc. The operating system also has at least 
one interrupt handler 170 for handling processor interrupts. Additional 
interrupts may be introduced at any time. The application programs that run 
on the mobile computer system 100 use the services of the operating system 
150 to interact with the hardware. 

Insertion/Removal Overview 



To simplify the operation of the mobile computer system 100, 
_ the expansion interface 110 has been designed to be simple to operate and 

^ ! 5 very robust. Specifically, the expansion interface 110 has been designed to 

allow users to insert or remove peripherals at any time. When a user does 
insert a peripheral into the expansion interface 110 or remove a peripheral 
from the expansion interface 110, the mobile computer system 100 
automatically responds with an appropriate reaction. When a user inserts a 
20 peripheral into the expansion interface 110, the mobile computer system 100 
first detects the inserted peripheral. Next, the mobUe computer system 100 
installs any appropriate device driver programs. Finally, the mobile 
computer system 100 and runs a designated application associated with the 
peripheral (if there is a designated application). When a user removes a 
25 peripheral from the expansion interface 110, the mobile computer system 100 
automatically removes any associated device driver programs and terminates 
any applications that require the removed peripheral. 

c 
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Peripheral Insertion Overview 

Figure 2 illustrates an overview of how the mobile computer 
system 100 handles peripheral insertions. As illustrated in Figure 2, a 
5 peripheral is inserted into the peripheral expansion interface at step 210. An 
interrupt handler identifies the insertion of peripheral into the peripheral 
expansion interface and then queues a peripheral insertion event onto an 
event queue at step 220. 



10 At step 240, an event handler detects the peripheral insertion 

event and executes a peripheral insertion routine. At step 250, the peripheral 
insertion routine attempts to locate a designated set-up utility in the memory 
space on the peripheral device. If a designated set-up utility is located, the 
peripheral insertion routine copies the designated set-up utility from the 

1 5 peripheral device memory into the main memory of the mobile computer 
system. The peripheral insertion routine men executes the set-up utility at 
step 255. 



After executing the set-up utility (if there was one), the 
20 peripheral insertion event handler routine attempts to locate a designated 
"welcome application" in the memory space on the peripheral device at step 
260. If a designated welcome application is located, the peripheral insertion 
routine launches the welcome application at step 265. At this point, the 
peripheral is initialized and any default application associated with the 
25 inserted peripheral is now executing. Thus, the insertion of the peripheral 
caused the mobile computer system to prepare itself for the use of the inserted 
peripheral. 
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Pori phPral Re-™* 1 Overview 

Figure 3 illustrates an overview of how the mobile computer 
sy stemhandles peripheral device removals. The flowchart of Figure 3 begins 
whenauserremovesaperipheral device from the peripheral expansion 
interface at step 305. An interrupt handler identifies the removal of the 
peripheral device from the peripheral expansion interface at step 320 and 
queues a peripheral device removal event onto an event queue. 

At step 340, the event handler handles the peripheral device 
removal event. The event handler handles me peripheral device removal 

event by updating system data structures to indicate the removal of the 

peripheral device. 

At step 370, the event handler determines if there is a set-up 
utility in the main memory mat is associated with the removed peripheral 
device Uadesigna.edse.-upunUryisloca.ed.theperipheraldeviceremoval 
routine of the even, handler executes a removal routine in the set-up utdrty. 
taone embodiment, the even, handler executes me set-up utility afstep 375 
with a "remove" indication that indicates the set-up utility should unirstall 
Wf and all drivers associated with the removed peripheral device. A, step 
380 dre set-up utility is removed from the mobile computer system's memory 
since the set-up utility for the peripheral is no longer needed. At this point, 
all driver programs associated with removed peripheral that are no longer 
25 needed have been removed from the mobile computer system 
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At step 390, the event handler queues a quit application event. 
In this manner, the currently executing application (that may be using the 
peripheral device) will gracefully cease execution. 

5 Peripheral Device Insertion 

The details behind having the mobile computer system 100 react 
appropriately when a user inserts a peripheral into the expansion interface 
110 are not trivial. The operation of the mobile computer system 100 in 
10 response to the insertion of a peripheral into the expansion interface 110 of the 
mobile computer system 100 will be presented with reference to Figures 2, 5, 
6, and 7. As set forth in Figure 2, one embodiment of the mobile computer 
system 100 uses an interrupt signal to notify the mobile computer system of 
peripheral device insertions. 

15 

Peripheral Insertion Interrupt Generation 

One embodiment of the mobile computer system 100 uses an 
interrupt generator circuit to generate peripheral device insertion interrupt 
signals. The interrupt generator circuit detects a card insertion by looking for 
20 a rising edge on an interrupt signal coupled the peripheral expansion 
interface 110. The interrupt generator circuit is actually a state based 
detection circuit wherein the interrupt generator circuit coupled to a signal 
from the expansion interface behaves in a different manner depending on a 
current state of the interrupt generator circuit. 

25 

Figure 4 illustrates a state diagram of the peripheral 
insertion/removal interrupt generator circuit. Initially, when the mobile 
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computer system is powered off, the interrupt generator circuit is in an off 
state 410. When the mobile computer system is powered on, the peripheral 
insertion/removal interrupt generator circuit enters a boot state 430 where the 
interrupt generator circuit determines if there currently is a peripheral device 

5 in the expansion interface. If the peripheral insertion/ removal interrupt 
generator circuit detects a peripheral device coupled to the expansion 
interface then the interrupt generator circuit proceeds to the "peripheral-in" 
state 460. Otherwise, if the peripheral insertion/ removal interrupt generator 
circuit does not detect a peripheral device coupled to the expansion interface, 

1 0 then the interrupt generator circuit proceeds to the ''no peripheral" state 480. 

In the peripheral-in state 460, the peripheral insertion/ removal 
interrupt generator circuit looks for the falling edge of a signal from the 
peripheral expansion interface. If a falling edge signal is detected then the 

1 5 peripheral insertion/removal interrupt generator circuit generates a 

peripheral removal interrupt and moves to the no peripheral state 480. In the 
no peripheral state 480, the peripheral insertion/ removal interrupt generator 
circuit looks for the rising edge of a signal from the peripheral expansion 
interface. If a rising edge signal is detected then the peripheral 

20 insertion/ removal interrupt generator circuit generates a peripheral insertion 
interrupt and moves to the peripheral-in state 460. 

Peripheral Insertion Interrupt Handling 

Referring to Figure 5, once a user inserts a peripheral at step 510 
25 an interrupt signal is generated. An interrupt handler takes over processing 
at step 520. At step 530, the interrupt handler determines if the interrupt was 
caused by a peripheral insertion. If the interrupt was caused by another 
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device, then some other interrupt handler handles the interrupt as set forth in 
step 535. 

When a peripheral device insertion is detected, the interrupt 
5 handler first forces a reset of the inserted peripheral device hardware at step 
540. The reset causes the inserted peripheral device hardware to enter an 
operational state such that the features of the peripheral device may be 
accessed. Next, the interrupt handler adjusts the chip select policy such that 
the memory and memory mapped input/ output on the peripheral card can 
10 be accessed by software running on the mobile computer system. In one 
embodiment, the interrupt handler simply adjusts the chip select policy to 
access the largest possible peripheral memory. At step 560, the interrupt 
handler places a peripheral insertion event into an event queue. The 
peripheral insertion event will cause the event handler to resume the 
1 5 peripheral configuration. After placing the peripheral insertion event into an 
event queue, the interrupt handler is finished handling the peripheral 
insertion interrupt. 

Peripheral Insertion Event Handling 

20 The event handler in the operating system will eventually 

encounter the peripheral insertion event. Figure 6 illustrates how the event 
handler handles a peripheral insertion event. Referring to Figure 6, the event 
handler first reads a predefined section of the peripheral memory space to 
obtain information about the inserted peripheral. Before the event handler 

25 performs the memory read, the event handler first sets the processor to issue 
the read with the greatest possible number of wait states. In this manner, the 
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memory read will work for even the slowest type of memory that can work 
with the processor. 



After reading the section containing the peripheral information, 
at step 620 the event handler validates the information that was read from the 
peripheral memory. If the peripheral information does not validate properly, 
then the event handler may inform the user of the invalid peripheral. The 
event handler may then abort the preparation for the invalid peripheral 
device at step 625. 

If the peripheral information read from the peripheral device 
validates properly, then the event handler prepares the handheld computer 
for interacting with the newly inserted peripheral device. The event handler 
first reads a value from the peripheral device that specifies the minimum 
number of wait states needed to handle the memory used in the peripheral 
device. The event handler then adjusts the processor's behavior, at step 630, 
to wait the minimum number of wait states when accessing the memory on 
the peripheral device. 

At step 650, the event handler then informs the operating system 
about the inserted peripheral. In one embodiment based upon the PalmOS 
from Palm Computing of Santa Clara, California, the event handler informs 
the operating system by updating system data structures to indicate the 
presence of a second memory card that may contain additional programs. The 
25 operating system will examine the added memory card and add the additional 
programs to the file system listing. 



20 
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Next, at step 660, the event handler determines if the peripheral 
device has an associated set-up utility. If the peripheral device has an 
associated set-up utility, then the event handler proceeds to step 663 where 
the event handler copies the peripheral device's set-up utility into the main 
5 memory of the mobile computer device. By copying the set-up utility into the 
main memory of the mobile computer device, the set-up utility will continue 
to be available even if the user later pulls out the peripheral device. After 
copying the set-up utility into the main memory of the mobile computer 
device, the event handler executes the set-up utility at step 665 with an 
10 "install" signal. The install signal informs the set-up utility that it should 
perform all the necessary peripheral device specific installation operations. 
Details on the set-up utility installation will be provided in the f ollowing 
section. 

j 5 After executing the set-up utility (if there was one), the event 

handler determines if the peripheral device has an associated "welcome 
application" at step 680. A welcome application is an application that has 
been designated by the peripheral device as an application that should always 
begin executing after the peripheral device has been installed. For example, a 

20 cellular telephone peripheral may designate a cellular telephone application 
as a welcome application that should be executed when the cellular telephone 
peripheral is installed. If a welcome application has been designated, then the 
welcome application is designated as the current application at step 685 such 
that the welcome application will begin execution. If no welcome application 

25 has been designated, then a default application is designated as the current 
application at step 683 such that the default application will begin execution. 
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In an embodiment that uses the PalmOS from Palm Computing, Inc., 
the launcher application is set as the default application In this manner, the 
launcher application will begin execution when no welcome application has been 
designated. Since the operating system is informed about the new peripheral device 
5 at step 650, the launcher application will now display any new applications that are 
newly available due to the insertion of the peripheral device. 

Peripheral Tn SP rtion Set-Up "Hlity Install Operation 

As illustrated in Figure 6, the event handler uses a set-up utility 

10 on the peripheral device to perform all peripheral specific installation 

operations. Figure 7 provides a list of operations that may be performed by a 
set-up utility. The reader should note that not all of the steps in Figure 7 need 
be performed by all set-up utility applications. Each peripheral set-up utility 
will only perform the operations necessary to prepare the installed peripheral 

15 device for operation. Furthermore, the set-up utility may perform operations 
not listed in Figure 7. 

Referring to Figure 7, the set-up utility program begins at step 
705. At step 710, the set-up utility may adjust the operation of the chip selects 
20 used to address the memory on the inserted peripheral device. The set-up 
utility program modifies the chip select policy to properly handle the actual 
size of memory & I/O address space contained within the peripheral device. 
The chip select policy is adjusted using the actual size of memory & I/O 
address space required by the peripheral software. 



25 



At step 715, the set-up utility allocates an amount of main 
memory that the peripheral needs for operation. The main memory will be 
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used to store state variables associated with the peripheral device. Memory is 
allocated by the set-up utility since some systems do not allow the allocation 
of memory within interrupt routines. 

At step 720, the set-up utility patches systems calls if necessary. 
In one embodiment, system calls may be listed in a jump table that contains a 
list of vectors to system calls. The set-up utility may patch a system call by 
copying a new system call routine into main memory and then changing the 
vector in the jump table to point to the new system call. 



10 



At step 730, the set-up utility may install new system calls. The 
new system calls may provide additional functionality to the operating 
system of the computer system. Some applications may be designed to use 
this additional functionality if and when it becomes available due to the 
1 5 insertion of a peripheral device. 

At step 740, the set-up utility may install a peripheral device interrupt 
handler. In one embodiment, an interrupt line is coupled to the expansion 
interface on the mobUe computer system. It should be noted that this 
20 expansion interface interrupt line is distinct from the peripheral insertion 
interrupt line. The peripheral device's set-up utility may install a peripheral 
device interrupt handler for that interrupt line. The newly installed 
peripheral device interrupt handler would obtain control of the processor at 
any time when an interrupt on the expansion interface interrupt line is 
25 asserted. 
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To conserve power, most mobile computer devices have a 
power management system that allows power to be saved by turning off 
circuits and devices that are not being used. To reduce power consumption, 
the peripheral device should install power management routines at step 750 
5 that will be called by the operating system at appropriate times. For example, 
a power off routine may be called when the mobile computing device is 
turned off. Similarly, an idle power down routine may be called when the 
mobile computing device has been idle for a predetermined period. A low 
power routine may be designated to be called by the operating system when 
10 the battery is low. 

Many peripherals will provide services to other application 
programs. For example, a wireless networking peripheral will provide 
network services such as TCP/IP to other applications. To provide the 
15 services to the other applications, such as a wireless networking peripheral 
may provide a set of shared libraries that may be accessed by other 
applications. The set-up utility should install such shared libraries as 
designated in step 760 of Figure 7. 



20 



Some peripherals will require background tasks to monitor 
activities on the peripheral device. The set-up utility should launch such 
background threads at step 770. 

Once the set-up utility has completed execution, the peripheral 
25 device is ready for operation. If the peripheral device provides shared 
services, those services are now available. If the peripheral device is 
controlled by a dedicated application, then that dedicated application will be 
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launched as the "welcome application" as depicted in steps 680 and 685 of 
Figure 6. 



Peripheral Removal 

Peripheral device removal is handled in a similar manner as 
peripheral insertion. In most cases, the removal is handled by first detecting a 
K^oval with an interrupt routine, modifying the chip select policy, queuing a 
,0 removal event from the interrupt routine, and then handling the removal 

event with an event handler. The even, handler handles the removal event by 
calling tire set-up utility associated with the peripheral device with a 
"removal" signal. 
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The peripheral removal handling may be interrupted by a 
hardware exception if any application program, interrupt routine, or other 
programattempts to access memory space that was mapped to the removed 

card. The change in chip select policy madeby the removal interrupt handler 
causes such hardware exception interrupts. 

Ppri pheral Pomnval Interrupt 

As illustrated in Figure 3, the removal of a peripheral device 
generates an interrupt at step 310. An interrupt handler then identifies the 
peripheral device removal interrupt and handles the peripheral device 
removal interrupt at step 320. Figure 8 illustrates one embodiment of a 
peripheral device removal interrupt handler. 



-18- 



WO 01/13222 PCIYUSOWIMS 

As illustrated in Figure 8, the interrupt handler begins at step 
820 AtsKpmtein^ptde^esiftheinterruptwascausedbya 

peripheral device removal. If no,, another interrupt handler handles the 
interrupt as show at step 835. 
5 whenaperipheraldeviceremmalintertupthasbeenidentined 
a, step 830, the peripheral removal interrupt rouune firs, reprograms the chip 
select* for me mobile computer system. The reprogramming indicates ma. 
any htureaccesswperipheraldev.ee memory space is an illegal access a, 
10 st e P 840.1nmismanner,ifanyprograma«emptemacce S samemo I y 

loC ariononmeperiphemlcard.,henabu S error exception will be generated. 
The bus error excepHon will be handled by a bus error routine that will be 
described in a later section of this document. 
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After reprogramming the chip selects a. step M0, the peripheral 
deviceremovalmterrup.rouunemenplacesaperipherairemovafeven.inan 

event queue a. step 860. The peripheral removal even, will cause the even, 
handler ,0 begin executing a peripheral removal rouune. The peripheral 
removal rouune of me even, handler will handle «he remainder of *e 
peripheral removal processing (unless a bus error occurs). 



f! li|iln I '1 Trm-"-' jvglt Handling 

The event handler in die operating system will eventually 
25 encounterdieperipheralremova.event.ha.wasplacedin.o.heeven.queue 
bytheinterrup.roumreuabuserrordoesno.occmtet.Hgure^iUusteates 



how 



the event handler handles a peripheral removal event. 
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Referring to Figure 9, the event handler first informs the 
operating system about the removed peripheral device at step 910. In one 
embodiment based upon the PalmOS from Palm Computing of Santa Clara, 
California, the event handler informs the operating system by updating 
system data structures to indicate one less memory card. The Operating system 
will then become aware of the removed card such that it may remove all references 
to the additional programs and data that were formerly available on that peripheral 
device. 



At step 920, the event handler stores the identifier of the 
application that is currently executing into a location that specifies the next 
application to execute. Next, at step 930, the event handler queues a quit 
event into the event queue for the currently executing application. In this 

1 5 manner, when the current application resumes execution, it will gracefully 
terminate itself. After terminating itself, the operating system will begin 
execution of the next application to execute. Since the identifier of the current 
application has been specified as the next application to execute, that 
application will restart itself. In this manner, the application will restart in the 

20 altered environment wherein the peripheral device has been removed. 

For example, if a web browsing application is currently using a 
wireless networking peripheral when the wireless networking peripheral is 
removed, then that web browsing application is automatically shut down. 
25 When the web browsing application attempts to restart, it may abort 
execution since no network peripheral is available to handle network 
requests. 
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At step 960, the event handler determines if the peripheral device 
had installed an associated set-up utility. If the peripheral device has an 
associated set-up utility, then the event handler proceeds to step 965 where 

5 the event handler executes the set-up utility at step 965 with an "removal" 
signal. The removal signal informs the set-up utility that it should perform all 
the necessary peripheral device specific removal operations. For example, the 
removal portion of the set-up utility will remove all interrupt handlers, 
shared libraries, device drivers, etc. that are associated with the removed 

10 peripheral. Details on the removal portion of the set-up utility will be 
provided in the following section. 

After executing the set-up utility (if there was one), the event 
handler returns such that the current application will resume execution. Since 
15 a quit application event had been scheduled by the event handler routine, the 
current application will terminate itself. Furthermore, the operating system 
will relaunch the current application since that application was designated as 
the "next" application to run in step 920. 

20 qp»-TT p Utility Remoygj Operation 

~ As Ulustrated in Figure 9, the event handler uses the set-up ■ 

utility that is resident in the main memory on to perform all peripheral 
specific removal operations. Figure 10 provides a list of operations that may 
be performed by the removal portion of the set-up utility. Again, the reader 

25 should note that not all of the steps in Figure 10 need be performed by the 
removal routines of all set-up utility applications. Each set-up utility removal 
routine will only perform the removal operations necessary to undo the 
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changes made when the set-up utility was run to prepare for the operation of 
the peripheral device. 

Referring to Figure 10, the set-up utility program begins at step 
5 1005. At step 1010, the removal routine of the set-up utility should terminate 
any background threads that were launched to help control the peripheral 
device. These threads should be terminated quickly to prevent the peripheral 
threads from attempting to access the removed peripheral device. 

j q At step 1020, the removal routine of the set-up utility removes 

any patches made to the systems calls if necessary. Any patch that requires 
access to the peripheral device is removed from the computer system. In one 
embodiment, certain system calls that are not directly associated with the 
removed peripheral device may be left in the mobile computer systems 

15 memory. In this manner, patches to cure operating system defects may be 
made to the operating system without requiring the user to obtain and install 
the operating system patch. Instead, when the user purchase a new 
peripheral device, the peripheral may insert an operating system patch if the 
patch has not already been made. However, the user may specify that such 

20 involuntary patches not be made unless necessary. 

At step 1030, the removal routine of the set-up utility removes 
any patches made to the system calls or any new system calls that were added 
during the peripheral installation as necessary. Any added system calls that 
25 require access to the peripheral device are removed from the computer 
system. As set forth in the previous paragraph, certain added system calls 
that are not directly associated with the removed peripheral device may be 
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left in the mobile computer systems memory. In this manner, extension to the 
operating system may be made to the operating system without requiring the 
user to obtain and install the operating system extensions. Thus, when a user 
purchases a new peripheral device, the peripheral may also provide operating 
5 system extensions. 

At stepl040, the removal routine of the set-up utility removes 
any interrupt handlers associated with the removed peripheral. Such 
interrupt handlers are no longer appropriate since the peripheral device has 
10 been removed. 

At step 1050, the removal routine of the set-up utility removes 
any power management routines associated with the removed peripheral 
device. Such power management routines are no longer appropriate since the 
1 5 peripheral device has been removed. 

At step 1060, the removal routine of the set-up utility removes 
shared libraries associated with the peripheral device that were installed 
when the peripheral device was inserted. Other operations to handle the 
20 peripheral removal may be performed as listed in step 1070. 

Once the removal routine of the set-up utility has completed 
execution, all of the system software associated with the peripheral device has 
been removed. When the removal routine of the set-up utility returns to the 
25 event handler, the event handler completes the peripheral driver removal 
process by deleting the set-up utility from main memory at step 970. Finally, 



WO 01/13222 PCT/US00/21915 

at step 990, the operating system will relaunch the current application by 
running the "next" application. 

Bug Error caused hv Peripheral Device Removal 

5 When a user removes a peripheral device from the expansion 

port of the mobile computer device, an executing application may mistakenly 
attempt to access a memory or input/output location in the peripheral 
device's memory space. When this occurs, a bus fault will occur since the 
processor will not receive any response from the removed memory location. 

10 To handle such situations, a special bus error exception routine resides within 
the operating system of the mobUe device. 

Figure 11 illustrates how one embodiment of a bus error 
exception routine may operate. When the bus error exception routine begins, 
the bus error exception routine first determines if the bus error was caused by 
the removal of a peripheral at step 1110. One simple method of making such 
a determination is to look at the address of the memory access that caused the 
bus error exception. If the address was within the peripheral device memory 
space, then the bus error was probably caused by a peripheral device 
removal. If the bus error was not caused by a peripheral removal, then other 
bus error handling code is executed at step 1115. 



15 



20 



When it has been determined that the bus error exception was 
caused by a peripheral removal, then the bus error exception handler 
25 attempts to kill the application program that caused the bus error exception 
and restore the state of the computer system to a state that the computer 
system was in before the application program that caused the bus error 
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began. The bus error exception handler begins this process at step 1130 by 
restoring a set of registers (including the stack pointer) to the values that these 
register had before the offending application was launched. One of those 
values is the identifier of the application being launched. 

5 

At step 1140, the bus error exception handler frees all the 
memory that was allocated by the application that caused the exception. In a 
PalmOS environment, the freeing of memory can easUy be performed since all 
memory allocations are marked by the identifier of the application that 

10 allocated the memory. Thus, the bus error exception handler simply frees all 
memory blocks marked with the application identifier of the offending 
applicatioa In a PalmOS system, a "SysAppExitO" system call can be used to 
free the allocated memory. The "SysAppExitO" system call "walks" through 
the memory heap looking for memory blocks associated with a particular 

1 5 application identifier and frees those memory blocks. 

At step 1150, the bus error exception handler closes all the 
databases that were opened by the application that caused the bus error 
exception. The "SysAppExitO" system call in the PalmOS system also 
20 performs the task of closing opened databases. The open databases are 
identified by the application identifier. 

At step 1160, the bus error exception handler frees up any other 
system resources allocated to the application that caused the bus error 
25 exception. In one embodiment, any semaphores owned by the application 
that caused the bus error exception are removed. At this point, the 
application has essentially been killed. 
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Next, at step 1165, the bus error exception handler informs the 
operating system that the peripheral device was removed such that the 
operating system does not attempt to use any resources from the peripheral 
5 device. In one embodiment based upon the PalmOS from Palm Computing of 
Santa Clara, California, the bus error exception handler informs the operating 
system by updating a system data structure to indicate that the second memory 
card has been removed from die mobile computer system 

j0 At step 1170, the bus error exception handler determines if the 

peripheral device had an associated set-up utility application. If a set-up 
utility application is located, the bus error exception handler calls the removal 
routine of the set-up utility at step 1175 to remove all drivers, interrupt 
handlers, patches, etc. associated with the peripheral device. After the set-up 

15 utility application has executed, the bus error exception handler removes the 
set-up utility from the mobile computer system memory at step 1180. 

Finally, at step 1190, the bus error exception handler sets the 
next application to run. The bus error exception handler may use the 

20 application identifier as the application that was just terminated in order to 
force the application to restart in the new execution environment without the 
peripheral device available. The restarted application will determine how it 
should proceed without the peripheral device. The bus error exception 
handler may also select an application other than the application that was 

25 terminated. In one embodiment, the bus error exception handler may 

designate the next application to run to be the launcher application for the 
mobile computer system. 
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Peripheral Device Examples 

To completely describe how the robust expansion system of the 
present invention may be used, a couple of expansion peripheral expansions 
are provided. 



MnHpm peripheral 
10 One type of peripheral that can be created is a modem 

peripheral for creating serial data connections through telephone lines. The 
modem peripheral should be accompanied with device drivers that control 
the operation of the modem peripheral. 



15 



20 



When a modem peripheral is inserted into the expansion 
interface of a computer system constructed according to the teachings of the 
present invention, the insertion will generate an interrupt. The interrupt will 
be classified as a peripheral insertion event such that a peripheral insertion 
event will be placed onto the event queue. 



The event handler will handle the peripheral insertion event as 
specified in Figure 6. Initially, the event handler will read and validate 
peripheral configuration information from the memory space of the 
peripheral device. Using the peripheral configuration information, the event 
25 handler will adjust the memory speed as designated in step 640. The event 
handler will then inform the OS about the new peripheral as designated in 
step 650. 
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V..' 

Next, the event handler copies a set-up utility located in the 
peripheral device memory space into the main memory. The event handter 
to calls the set-up utility with an instell signal to have the set-up utility 
5 install the necessary driver software. 

The modem peripheral's set-up utility will then install all the 
driver software necessary to allow applications to use and access the modem 
peripheral. The modem peripheral's set-up unlit, will install shared libraries 
,0 forthemodemandaninterrupthandlerforservicingthemodem. lnone 
embodiment, the modem set-up utility may designate the modem as the 
default Universal Asynchronous Receiver Transmitter (UART) such that 
future serial accesses attempt to use the modem. 

O )5 tte modem peripheral may include a default application 

program such as a terminal emulation program. That terminal enrnlauon 
program may be designated as the "welcome application" on the modem 
peripheral device such that the terminal emulation application au.omat.caUy 
launches after inserting tie modem peripheral into Ore expansion interface. 

When the modem peripheral is removed, another interrupt will 
be generated and identified as an interrupt caused by a peripheral device 
removal. The removal will cause the interrupt handler to queue a peripheral 
removal even,. The event handler will then process the periphera. removal 
25 eventasdesignatedinrigure*. SpecificaUy, the removal even, handler wdl 
Worm die OS drat the peripheral has been removed and queue a quit even, 
for .he currently executing applicadon. The peripheral remove! even. 
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handler next calls the removal routine of the set-up utility to remove all the 
modem drivers that were installed by the install routine in the set-up utility. 
Finally, the peripheral removal event handler removes the set-up utility from 
the mobile computer system's main memory. 

If the user pulls out the modem peripheral while the terminal 
application is accessing memory space mapped onto the modem peripheral 
then a bus error exception may be generated. The bus error exception will be 
handled by a bus error exception handler. That bus error exception handler 
will then perform the operations specified in Figure 11. Specifically, the bus 
error exception handler will manually kill the currently executing application 
(which could be the terminal application). Next, the bus error exception 
handler will call the removal routine of the set-up utility to remove all the 
modem drivers that were installed by the install routine in the set-up utility. 
The bus error exception handler then removes the set-up utility from the 
mobile computer system's main memory. 



Bark-u p peripheral 

Not all peripheral devices will need sophisticated driver 
software. For example, a simple portable back-up peripheral can be 
implemented with the teachings of the present invention just using a flash 
memory card peripheral and a back-up program. Specifically, the flash 
memory card peripheral will designate the back-up program as the welcome 
application such that the back-up application will be automatically launched 
when the peripheral device is inserted 
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When the back-up peripheral is inserted, the interrupt routine 
will place a peripheral insertion event onto the event queue. The event 
handler will handle the peripheral insertion event as specified in Figure 6. 
Initially, the event handler will read and validate peripheral configuration 
information from the flash memory space of the peripheral device. 
Specifically, the event handler will adjust the memory speed as designated in 
steps 640 to accommodate the flash memory card. The event handler will 
then inform the OS about the new peripheral as designated in step 660. 

The event handler will then look for a set-up utility in the flash 
memory. Since the back-up peripheral does not need any special drivers, the 
event handler will not find a set-up utility and proceed to look for a welcome 
application. The installer will then designate the back-up welcome 
application as the next application to execute as specified in steps 680 and 685. 



The welcome application (the back-up application) with then 
begin executing. In one embodiment, the back-up application will ask the 
user if he/she wishes to back-up or restore data from the flash memory card. 
If the user selects a back-up, then the back-up application will proceed to 

20 back-up the contents of the mobile computing device's main memory into the 
flash memory of the back-up peripheral. Standard techniques such as 
incremental back-ups may be performed to save time and power 
consumption. If the user wishes to restore data from the back-up flash 
peripheral then the back-up application will present a series of screen 

25 displays that will allow the user to restore all or some of the lost data. 
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A Second External Interface With VO Support 



Mobile computer systems, such as the mobile computer system 
illustrated in Figures 1A and IB, often use simple input mechanisms for 
inputting data. For example, the mobile computer system illustrated in 
Figures 1A and IB provides a digitizer pad that can be written on using a 
stylus. The user's handwriting is then interpreted by the interface software to 
generate normal character data such as ASCII (American Standard Code for 
Information Interchange) or UNICODE character values. Some mobile 
computer systems use a small keypad illustrated on the display for entering 
text. While such simple input mechanisms are useful while traveling, many 
users desire to have standard input mechanisms when the mobile computer 
system is being used in a normal work environment such as an office. 

The most standard computer input mechanism is the well- 
known QWERTY keyboard. A QWERTY provides the most well known user 
interface to users. Another popular input mechanism is speech to text 
systems that interpret what a user says and generates a stream of text. 
Dragon System's Naturally Speaking and IBM's ViaVoice are examples of 
speech to text systems. 

Alternate Input support 

Most portable computer systems only provide one mechanism 
for inputting data. To provide a flexible system of allowing data input, the 
present invention introduces an alternative input port. Specifically, the 
present invention discloses an input port that automatically recognizes and 
accepts input from external input devices. 
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Referring to Figure 1A, the mobile computer system includes an 
external interface 150. The following table describes the pin-out of the 
external interface 150: 



Table 1 


INTERFACE 


CONTACT FUNCTION 1 


CONTACT 




1 


RXD: Serial Receive 


2 


alternate cradle detect pin 1 


3 


Synchronize Interrupt 


I 4 


GND: Common Ground 




USB: Data- 


I 5 
I 6 


USB: Data+ 




Peripheral Charge Power 


|8 


TXD: Serial Transmit 



The external interface 150 includes the contacts necessary for 
coupling to another computer system in two different manners: Universal 
Serial Bus and Serial Port. As illustrated in Table 1, the external interface 150 

10 includes a set of Universal Serial Bus (USB) signals for communicating with a 
computer system that has a Universal Serial Bus port. Specifically, the 
external interface 150 has a USB Data* signal, a USB Data- signal, and a 
common ground. fThe USB VBus power signal may be used in other 
implementations, not shown.) The external interface 150 also includes a Serial 

1 5 Transmit, a Serial Receive, and a Common Ground for communicating with a 
computer system or peripheral through a standard serial port. The external 
interface 150 further includes a synchronization interrupt line that activates 
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an interrupt on the mobile computer system such that the mobile computer 
can handle the interrupt. In one embodiment the interrupt is used to activate 
a synchronization program use to synchronize information on the mobile 
computer system with another computer system. 

5 

The external interface 150 further includes an alternate cradle 
detect pin. The alternate cradle detect pin is an input pin that is activated by 
certain peripherals that couple to the external interface 150. One class of 
peripheral devices that may activate the alternate cradle detect pin are input 
1 0 devices that are coupled the external interface 150. The operating system in 
the mobile computer system 100 periodically polls the alternate cradle detect 
pin such that when the alternate cradle detect pin is activated, the operating 
system launchers a handler for handling user input from the external interface 
150. 

15 

Figure 12 illustrates one embodiment of a flow diagram that 
describes how one embodiment of a mobile computer system can handle the 
alternate cradle detect pin. Referring to Figure 12, the mobile computer 
system polls the alternate cradle detect pin. at step 1210. At step 1220, the 
20 mobile computer system determines if the alternate cradle detect pin was 
activated. If the alternate cradle detect pin was not activated, then the mobile 
computer system continues to poll the alternate cradle detect pin by returning 
to step 1210. If the alternate cradle detect pin was activated, then the mobile 
computer system proceeds to step 1230. 

25 

At step 1230, the mobile computer system launches a 
background task for handling the input device that was recently connected. 
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From this point forward, the background task may be used to perform the 
steps of the method. At step 1240, the input port that had a device connected 
is identified. In one embodiment, the input device may use the serial port 
interface or the Universal Serial Bus interface. A defined set of protocols can 
5 be used to identify an input device coupled to the Universal Serial Bus 

interface. In another embodiment, step 1240 is not required since only one of 
input interfaces may be used for input devices. For example, only the serial 
port interface may be used. 

1 o At step 1250, the background task initializes the interface port to 

which the input device was connected. At step 1260, the background task 
now monitors the interface port to which the input device was connected. 
When any input or change on the monitored port is detected, the background 
task handles the input/ change. 

15 

At step 1270, the background task determines if the input device 
was detached from the input port. This can be detected by testing the 
alternate cradle detect pin occasionally (polling). If the input device was 
detached, then the background task proceeds to step 1275 where the input 
20 port is closed and the background task is shut down. The method proceeds 
back to step 1210 where the alternate cradle detect pin is then polled. 

At step 1280, the background task determines if data was 
received from the input device. If data was received from the input device, 
25 the background task queues an input event to the event queue. The queued 
input event specifies that data from the external input device has been 
received. For example, if a keyboard device was coupled to the external 
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interface, then the background task may queue a keyboard event in the event 
queue. 



Alternate Synchronization 

5 The alternate cradle detect pin may be used for other purposes 

as well. One alternate use in a current embodiment allows the alternate 
cradle detect pin to specify an alternate synchronization data path. Referring 
back to Table 1, the external interface includes a USB Data+ signal, a USB 
Data- signal, and a common ground. These USB data signals allow the mobile 

10 computer system to exchange information with a personal computer system. 

One of the primary uses for the USB Data signals is to allow the 
mobile computer system to synchronize its information with information on a 
personal computer system. Such synchronization systems are well-known. 

1 5 One example is disclosed in U.S. patent 5,884,323, issued March 19, 1999 
entitled "Extendable Method And Apparatus For Synchronizing Multiple 
FUes On Two Different Computer Systems." As specified earlier with 
reference to Table 1, the external interface 150 may include a synchronization 
interrupt line that may be used to activate a synchronization program. 

20 Normally, the synchronization program would attempt to synchronize with 
another computer system coupled through the USB connection 

In some situations, a user may wish to synchronize with a 
remote computer system that is not available through the USB connection. 
25 For example, a modem that uses the serial data connection on the external 
interface allows a mobile computer may remotely connect to other computer 
systems through a telephone line. One connected, the mobile computer 
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system may synchronize with a remote computer system. An example of 
such an application is provided in the U.S. patent application entitled 
"Method And Apparatus For Synchronizing A Portable Computer System 
With A Desktop Computer System" filed on January 30, 1997 having serial 
5 number 08/792,166. 

To handle such alternate synchronization environments, the 
synchronization program may test the alternate cradle detect before 
commencing with a synchronization. Specifically, if the interrupt routine that 

1 0 handles synchronization interrupt requests first test the alternate cradle pin to 
detect if an alternate cradle is active. When the alternate cradle pin is 
activated, the synchronization interrupt routine launches an alternate 
synchronization program that will use an alternate synchronization path such 
as the serial data interface on the external interface. Thus, hardware coupled 

15 to the external interface, such as modems, should activate the alternate cradle 
detect pin. Thus, when a synchronization interrupt request is made, the 
synchronization interrupt handler can launch an associated alternate 
synchronization program. 

20 The foregoing has described a method and apparatus for 

implementing a robust external interface for a computer system. It is 
contemplated that changes and modifications may be made by one of 
ordinary skill in the art, to the materials and arrangements of elements of the 
present invention without departing from the scope of the invention. 
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